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(54) System providing for multiple virtual circuits between two network entities 



(57) Computers sending IP datagrams over an ATM 
network are generally capable of operating multiple 
simultaneous virtual circuits over tiie network. However, 
in doing so» they normally only set up one virtual circuit 
to each destination IP address so tiiat in order to test 
the simultaneous operation of N virtual circuits by a 
computer under test, N target computers are needed. 
To enable a single computer (T) to provide tiie destina- 
tion endpoints for multiple virtual circuits (SVC) from a 
computer (IM) under test, botti computers (M,T) are allo- 



cated a plurality of virtual IP addresses (lM{j).lT(o) 
tiie target computer (T) is additionally provided with a 
module running address-changing processes (70,71) 
tiiat avoids tiie IP layers (20) of botii computers from 
rejecting IP datagrams (25A.25B) addressed with tiie 
virtual IP addresses. As a result, each computer (M.T) 
can be addressed witii any of a plurality of IP addresses 
and each will result in the creation of a respective virtual 
circuit (SVC) between the computers (M,T). 
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Description 
Reldofthe Invention 

The present invention relates to a system providing 
for multiple virtual circuits between two network entities 
for use in particular, but not exclusively, in the testing of 
network node apparatus providing IP messaging over 
an ATM network. 



Background of the Invention 

As is well-known, the Internet Protocol (IP) uses a 
scheme of IP addresses by which every connection of a 
node to the Internet has a unique IP address. IP 
addresses are high-level addresses in the sense that 
they are independent of the technology used for the 
underlying network to which a node is connected. Each 
node will also have a low-level, network-dependent 
address (often caliled the MAC address) that is actually 
used for addressing at the network level and the IP pro- 
tocol suite includes a address reolution protocol (ARP), 
logically positioned below the IP layer itself, that is 
responsible for translating between IP addresses con- 
tained in a message and the local MAC addresses. 

An increasingly important technology for local area 
networks is ATM. ATM (Asynchronous Transfer Mode) is 
a multiplexing and switching technique for transferring 
data across a network using fixed sized cells that are 
synchronous in the sense that they appear strictly peri- 
odically on the physical medium. Each cell comprises a 
payload portion and a header, the latter including a label 
that associates the cell with an instance of communica- 
tion between sending and receiving network end sys- 
tems; this instance of communication may involve the 
transfer of many cells from the sending end system, 
possibly to multiple receiving end systems. ATM is asyn- 
chronous in the sense that cells belonging to the same 
instance of communication will not necessarily appear 
at periodic intervals. 

In ATM, the labels appended to the cells are fixed- 
size context dependent labels, that is, they are only 
understandable in the light of context information 
already established at the interpreting network node, 
the label generally being replaced at one node by the 
label required for the next node. In other words, ATM is 
a virtual circuit technology requiring a set up phase for 
each instance of communication to establish the appro- 
priate label knowledge at each node. Of course, to set 
up a desired communication, it is still necessary to iden- 
tify uniquely the nodes forming the communication end 
points and this is achieved by using ATM addresses, 
generally of a significance limited to the particular ATM 
network concerned. 

The process of sending IP messages (datagrams) 
over a ATM networK including the operation of the 
required ATM ARP system, is set out in RFC 1577 of the 
IETF Internet Engineering Task Force) dated January 



1993. This RFC assumes an arrangement in which a 
sending node will only establish a single vircuit circuit to 
a given destination IP address (of course, this one vir- 
cuit circuit may carry multiple connections between 
5 respective pairings of high-level end points in the 
nodes). 

Figure 1 of the accompanying drawings is a dia- 
gram illustrating the basic mechanism by which two 
machines M and T exchange IP datagrams over a 

10 switched virtual circuit (SVC) established across an 
ATM network The machines M and T have respective 
IP addresses 1^ and It and respective ATM addresses 
Am and Ar; each machine knows its own addresses. An 
ATMARP server S knows the IP and ATM addresses of 

15 all active nodes on the network, including machines M 
and T; more particularly, server S maintains an ARP 
table 15 associating the IP address of each node with its 
ATM address. The server S maintains open a respective 
SVC (switched virtual circuit) to each active node and 

20 the identity of this SVC is heki in the ARP table 1 5; thus, 
in the Figure 1 example, the server S is in communica- 
tion with machine M over an SVC identified as SVC "r 
at the server, and the server S is in communication with 
machine T over an SVC identified as SVC "2" at the 

25 server S. At machines M and T these virtual circuits are 
independently identified - thus at machine M its SVC to 
the server S is kJentrf ied as SVC **3" whilst at machine T 
its SVC to the server S is identified as SVC "5". 

The communications intertece 18 in each of the 

30 machines M and T comprises three main layers, 
namely: an IP layer 20 responsible for forming IP data- 
grams (including source and destination IP addresses) 
for transmission ad for filtering incoming datagrams; an 
intermediate IP/ATM layer 21 for determining the SVC 

35 corresponding to the destination IP address of an out- 
going datagram; and an ATM layer 22, including the low- 
level network interface hardware, for sending and 
receiving datagrams packaged in ATM cells over SVCs. 
The IP/ATMIayer 21 maintains an ARP cache table 

40 27 which like the table 1 5 of the server S contains asso- 
ciations between IP address, ATM address and SVC. 
Thus, table 27 of machine M contains an entry of the IP 
address Is, ATM address As, and SVC identity "3" for 
the server S. and similarly, table 27 of machine T con- 

45 tains an entry of the IP address Is, ATM address Ag, and 
SVC identity "5" for the server S. The cache table 27 
only holds information relevant to current SVCs of the 
machine concerned so that during the initial establish- 
ment of a SVC to a new destination, the cache table 

so must be updated with relevant information from the 
ATMARP server S; this general process will be 
described in more detail hereinafter witii reference to 
Figure 2. For the present, it will be assumed that an 
SVC has already been established between machines 

55 M and T and that the cache tables contain the relevant 
information (in particular, cache table 27 of machine M 
contains an entry with the IP address \j, ATM address 
Af, and SVC identity "4" for machine T, and cache table 
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27 of machine T contains an entry with the IP address 
Im. ATM address A^, and SVC identity "9" for machine 
M). 

Considering now the case of a high-level applica* 
tion in machine M wanting to send a message to 
machine T, this application passes the message to the 
IP layer 20 together with the destination IP address It- 
IP layer 20 packages the message in one (or more) dat- 
agrams 25A with a destination IP address of Ij and 
source Ip address of 1^. Datagram 25A is then passed 
to the IP/ATM layer 21 which executes an IP-to-SVC 
lookup task 30 to determine from taiAe 27 the SVC to be 
used for sending the datagram to its destination address 
\j, in the present case, table 27 returns the SVC identity 
"4" and the layer 21 passes this identity together with 
the datagram 25A to the ATM layer 22 which then sends 
the datagram in ATM cells on SVC "4". The datagram Is 
in due course received by machine T and passed up by 
layers 22 and 21 to the IP layer 20 where a filtering task 
29 determines from the datagram destination address 
that the datagram is indeed intended for machine T; the 
contents of the datagram are then passed to the rele- 
vant high-level application. In the present example, this 
high-level application produces a reply message which 
it passes to the IP layer 20 together with the required 
return address, namely the source IP address in the 
received datagram 25A. IP layer 20 generates datagram 
25B with the received return address as the destination 
address, the IP address Ij of machine T being included 
as the source address. The datagram 256 is passed to 
IP/ATM layer 21 where IP-to-SVC lookup task 30 deter- 
mines from cache table 27 that the required destination 
can be reached over SVC "9". This information together 
with datagram 25B is then passed to ATM layer 22 
which transmits the datagram in ATM cells over SVC "9" 
to machine M. When the datagram is received at 
machine M it is passed up to the IP layer 20 where it is 
filtered by task 29 and its contents then passed on to the 
relevant high-level application. 

Figure 2 of the accompanying drawings illustrates 
in more detail the functioning of the IP/ATM layers 21 of 
machines M and T in respect of datagram transmission 
from machine M to machine T, it being appreciated that 
the roles of the two layers 21 are reversed for transmis- 
sion in the opposite direction. More particularly, upon 
the IP-to-SVC lookup task 30 being requested to send a 
datagram to IP address \j, it first can-ies out a check of 
the cache table 27 (step 31) to determine if tiiere is an 
existing entry for \j (and thus an SVC. assuming that 
entries are only maintained whilst an SVC exists). Step 
32 checks the result of this lookup - if ari SVC already 
exists (in this case. SVC M"). then step 39 is executed 
in which the datagram is passed together with the iden- 
tity of the relevant SVC to the ATM layer 22; however, if 
the lookup was unsuccessful, task 30 executes steps 33 
to 38 to set up an SVC to destination \j before executing 
step 39. 

The first step 33 of the setup process involves the 



sending of an ARP request to ttie ATMARP server S 
over the relevant SVC requesting the ATM address cor- 
responding to It. Server responds with ATM address Ap 
which is received by task 30 at step 34. 

5 Task 30 now updates the cache table 27 with the IP 
address It and ATM address Af (step 35). Next, task 30 
requests (step 36) tiie ATM layer 22 to establish a new 
SVC to ATM address % and this initiates an SVC setup 
process 28 which may be executed in any appropriate 

10 manner and will not be described in detail herein. In due 
course, process 28 returns the identity of the SVC tiiat 
has been set up to A^ (in this case. SVC "4"), tiiis iden- 
tity being received at step 37 of task 30. Rnaily, cache 
table 30 is updated at step 38 by adding the SVC iden- 

15 tity ("4") to the entry already containing It and Ar. 

In machine T, the setup of the new SVC to tiie 
machine from machine M is handled by the setup proc- 
ess 28 of machine T. TTie process 28 informs the 
IP/ATM layer that a new SVC has been setup and this 

20 triggers execution of an update task 40 to update the 
cache table 27 of machine T. More particularly, on tiie 
new SVC indication being received (step 41), a first 
update step 42 is carried out to add an entry to the table 
confining the identity of the new SVC (in the present 

25 example "9"), and the ATM address Ay of the node at 
the other end of the SVC; at this stage, tiie correspond- 
ing IP address is not known to machine T. In order to 
obtain this IP address, an inverse ARP request Is now 
made to machine M (step 43). In due course a response 

30 is received (step 44) containing tiie IP address of 
machine M. The cache table 27 is then updated at step 
45 witii the IP address 1^ of machine M and the IP/ATM 
layer is now ready to effect IP-to-SVC translations for 
datagrams Intended for machine M. 

35 The inverse ARP request sent by machine T to 
machine M Is handled by an inverse ARP task 50 tiiat 
examines the request (step 51) and on finding that it 
contains tiie ATM address A|^. responds witti the IP 
address l|^ of machine M (step 52). 

40 To focilitate explanation of the preferred embodi- 
ment of tiie invention hereinafter, the messages across 
the boundary between tiie IP/ATM layer 21 and the ATM 
layer 22 have been labelled in Figure 2 as follows where 
superscript 'T" indicates an outgoing message (ttiat is. 

45 from tiie IP/ATM layer to the ATM layer) and the super- 
script "R" indicates incoming messages (that is, from 
tiie ATM layer to the IP/ATM layer): 

XI ^ • outgoing ARP request; 

50 X2^ - incoming ARP response; 

X3^ - outgoing SVC setup request; 

X4" - incoming SVC setup done indication; 

X5^ - incoming new SVC indication; 

X6^ - outgoing INARP request; 

55 X6^ • incoming INARP request; 

X7''^ - outgoing INARP response; 

X8^ • outgoing datagram; 

XS'^ - incoming datagram. 
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It will be appreciated that machines connecting to 
an ATM networK such as niachines M and T as well as 
the server S, are designed to handle a large number of 
virtual circuits simultanteously. If in testing such a 
machine (machine M in the following discussion) it is 
desired to fully stress the machine under test, then the 
design limit of concun'ently operating virtual circuits 
must be simultaneously used. However, as already Indi- 
cated, current practice is that only one virtual circuit is 
established to each distinct IP address. As a result, 
since generally each machine that might be used to test 
machine M has only one network connection and there- 
fore only one IP address, if machine M is designed to 
operate up to N virtual circuits simultaneously, then it 
requires N machines to test machine M. Such an 
arrangement is illustrated in Figure 3 where the N 
machines are constituted by the server S and (N>1) 
other machines here represented as machines T1 to 
T(N-1). Such an arrangement is generally impractical as 
N may be as high as 1024 or more. 

It is an object of the present invention to provide a 
mechanism that enables, inter alia, the foregoing test 
problem to be overcome. 

Summary of the Invention 

According to the present invention, there is pro- 
vided a system in which a plurality of entities are con- 
nected to a network ad can exchange messages across 
virtual circuits set up over the network between said 
entities, each entity having a operative high-level 
address on the network, and each entity comprising: 

- high-le/el messaging means for handling mes- 
sage transmission and receipt on the basis of the 
aforesaid high-level addresses, the high-level mes- 
saging means comprising means for including in 
outgoing messages the operative high-level 
address of the entity as a source identifier and the 
operative high level address of the intended recipi- 
ent entity as a destination identifier, and means for 
filtering incoming messages according to the desti- 
nation identifier contained in the message; 

- virtual-circuit means for providing virtual circuits 
between the entity and other entities, there being a 
respective virtual circuit br each different destina- 
tion identifier in use, and 

- intermediate means for passing an outgoing mes- 
sage from the high-level messaging means to that 
one of the virtual circuits provided by the virtual-cir- 
cuit means which corresponds to the destination 
identifier of the message; 

characterised in that each of a first and a second one 
of the entities has a plurality of virtual high-level 
addresses associated with it that are different from the 
operative high-level address of the entity, the virtual 
high-level addresses being usable by the messaging 



means of the first and second entities as destination 
identifiers in outgoing messages: and In that between 
the intermediate means of the first and second entities, 
there are provk^ed address-changing means respon- 

5 sive to each of at least some of the messages sent 
between these entities with a said virtual high-level 
address as its destination kientifier. to change that 
address to the operative high-level address of the core- 
sponding entity and to change the operative high-level 

10 address provided as the source identifier of the mes- 
sage into one of the said virtual high-level addresses 
associated with the sending entity in dependence on the 
virtual high-level address initially provided as the desti- 
nation identifier of the same message. 

15 By virtue of this arrangement, it is possible to estab- 
lish a plurality of virtual circuits between the first and 
second entities by using the different virtual high-level 
addresses of the entities as the destination klentifiers in 
messages exchanged between the entities, the receiv- 

20 ing high-level adressing means accepting such mes- 
sages due to the address-changing means having 
changed the destination kjentifier to tiie operative high- 
level address of tiie receiving entity. By also changing 
ttie source kientifier, it is possble to retain in the mes- 

25 sage information sufficient to associate any reply mes- 
sage witii a particular one of the virtual circuits 
established with tiie sending entity (in particular, tiie 
reply message can be sent back over the same virtual 
circuit as the message to which it is a reply - however, if 

30 desired, it is also possible to use a separate virtual cir- 
cuit for the reply messages). 

Preferably, the address-changing means comprises 
first address-changing functionality for effecting tiie 
albresakJ changes for messages sent from the first 

35 entity to the second entity, and second address-chang- 
ing functionality for effecting these changes for mes- 
sages sent from the second entity to the first entity, both 
tiie first and second address-changing functionalities 
being provkied in tiie second entity. This configuration is 

40 well suited for testing the ability of network node appa- 
ratus to ooncun-ently operate a plurality of virtual circuits 
where tiie network node apparatus is operative to 
establish a virtual circuit for each different high-level 
destination address being handled; more particularly. 

45 tiie network node apparatus serves as tiie afbresaxJ 
first entity, and is caused to send messages to at least 
some of the vial high-level addresses associated witfi 
tiie second entity. By placing tiie address-changing 
means in tiie second entity, no nrxxlifications are 

50 needed to the network node apparatus in order for it to 
be able to establish a plularity of virtual circuits with ttie 
second entity 

Advantageously, tiie address-changing means 
effects a predetermined transformation on the virtual 

55 high-level address forming the initial destination identi- 
fier of a said message in order to form the virtual high- 
level address to be used for the source identifier of that 
message. For example, this transformation may simply 
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involved changing the address by one (where the 
address is numeric in form). 

The present invention is particularly applicable to 
systenrts in which the high-level addresses are IP 
addresses and the network is an ATM network 

Brief Description of the Drawings 

A system embodying the invention will now be 
described, by way of non-limiting example, with refer- 
ence to the accompanying diagrammatic drawings, in 
which: 

. Hgure 1 is a diagram of a known system for send- 
ing IP datagrams over a ATM network 
between two machines M and T; 

. Figure 2 is a diagram illustrating the steps candied 
out by the Figure 1 system in establishing 
a virtual circuit between machines M and 
T: 

. Rgure 3 is a diagram of a known test arrangement 
for testing the ability of a machine M to 
concurrently operate multiple virtual cir- 
cuits; 

. Hgure 4 is a diagram showing a test arrangement 
embodying the invention for testing the 
ability of a machine M to concun-ently 
operate multiple virtual circuits; 

. Figure 5 is a diagram similar to Figure 1 but show- 
ing a system embodying the invention in 
which multiple virtual circuits are estab- 
lished between machines M and T; 

. Rgure 6 is a diagram illustrating the processing 
effected by a module VNS disposed in 
machine T of the Figure 5 system when 
machine M initiates the opening of a new 
virtual circuit between machines M and 
T; and 

. Figure 7 is a diagram illustrating the processing 
effected by a module VNS disposed in 
machine T of the Figure 5 system when 
machine T initiates the opening of a new 
virtual circuit between machines M and T. 

Best Mode of Carryinp Out the Invention 

The enibodiment of the invention now to be 
described provides a system in which it is possible to 
establish a plurality of SVCs (switched virtual circuits] 
across an ATM network for the exchange of IP data- 
grams between two machines M and T whereby it is 
possible to test the ability of machine M to concun^ently 
operate a plurality of virtual circuits without needing to 
provide a respective destination machine for each SVC 
operated by machine M. The overall test arrangement is 
illustrated in Figure 4 where machine M operates N 
SVCs over ATM network 10, one SVC being with 
ATMARP server S and (N-1) SVCs being with machine 



T. According to the preferred embodiment, the estab- 
lishment of multiple concurrent SVCs between machine 
M and T is effected without modification to machine M. 
Rgure 5 shows a system embodying the present 

5 invention, tiiis system being similar to that of Figure 1 
but being operative to provide a plurality of concun-ent 
SVCs 65 between machines M and T. In the Figure 5 
system, tiie machines M and T and tiie server S are 
assumed to operate in the same way and have the 

10 same IP and ATM addresses as in Figure 1 ; in addition, 
in Figure 5 tiie same SVCs are established between the 
server S and the machines M and T as in Figure 1 . The 
Figure 5 system includes, however, added functionality 
provided by processes 70 and 71 which in Figure 5 are 

15 shown independent of machines M and T but in practice 
would be provided either disti'ibuted between machines 
M and T or wholly in one of tiiese machines; in a pre- 
fen'ed embodiment, tiie processes 70 and 71 are pro- 
vided in machine T. 

20 In accordance with tfie present invention, each 
machine M and T is allocated a numt)er of virtual IP 
addresses different from its operative (or "real") IP 
address (this latter address being tiie one which tiie IP 
layer knows about for inclusion as tiie source address in 

25 outgoing datagrams and upon which filtering is earned 
out by task 29). Thus, machine M is allocated virtual IP 

addresses \f^^^y 1^(2). Imq) -: similarly, machine T is 

allocated virtual IP addresses lj(i). Ij(2) lT(i) -. 

Each of these virtual IP addresses is entered into 

30 table 15 of ATMARP server S together with tiie ATM 
address of tiie corresponding one of the machines M.T; 
tiius virtual IP address is associated witii ATM 
address A^ and virtual IP address is associated 
with ATM address Af. 

35 Now. if tiie communications interface 1 8 of machine 
M is asked to send a message to IP address Ij^y IP 
layer 20 will construct a datagram 25A having a destina- 
tion address of Ij^jj and a source address of 1^- The IP- 
to-SVC task 30 of IP/ATM layer 21 then acts in the man- 

40 ner already described to fetch the ATM address corre- 
sponding to lT(j) from server S and set up an SVC (here 
identified by "p") towards machine T; the cache table 27 
is updated appropriately The datagram 25A is now sent 
by ATM layer over SVC(p) to machine T 

45 If no f urtiier action is taken, tiie datagram 25A, after 
receipt at machine T. will be rejected by tiie filter task 29 
as the destination address Ijq of the datagram differs 
from the operative IP address \j known to task 29 of 
machine T. Accordingly, a process 70 is provided that 

50 recognises the destination address of datagram 25A as 
being a virtual IP address of machine T and substitutes 
the real IP address of machine T for tiie virtual address 
in the destination field of tiie datagram 25A. The data- 
gram will now be allowed through by filter task 29 of 

55 machine T. 

However, a furtiier difficultiy remains. If only tiie 
destination address is changed, tfie resultant datagram 
contains no indication tiiat the datagram was not ordi- 
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narily sent with the real IP address of machine T; any 
reply will therefore be sent on an SVC set up to take dat- 
agrams from machine M to the real IP address of 
machine M. This SVC would end up taking all the reply 
messages for messages sent from machine M to 
machine T over all the SVCs set up in respect of the vir- 
tual IP addresses allocated to machine T. This is clearly 
undesirable. To avoid this, the source address of data- 
gram 25A is also changed by process 70. More particu- 
larly, the source address is changed from the real IP 
address of machine M to one of the virtual IP addresses 
'mg) 0^ machine, the virtual address chosen being 
dependent on the original virtual IP address forming the 
destination address of the datagram. As a result, all dat- 
agrams 25A having the same virtual destination 
address end up after operation of process 70 as data- 
grams 25AA with the same virtual source address, 
whereas datagrams 25A having different initial virtual 
destination addresses end up as datagrams 25AA with 
different source addresses. The process of changing 
the source address preferably Involves a predetermined 
transformation of the virtual destination address - for 
example, to obtain the required virtual source address, 
the virtual destination address can simply be incre- 
mented by one (there would thus exist, for example, a 
set of even virtual IP addresses for machine M and a 
corresponding set of odd virtual IP addresses for 
machine T, each even virtual IP address of machine M 
being associated with the immediately adjacent, lower- 
valued, odd virtual IP address of machine T). 

The address-changing process 70 must be carried 
out on datagram 25A after operation of the IP-to-SVC 
task 30 In machine M and prior to the filter task 29 in 
machine T In addition, whilst the two address-hanging 
operations of process 70 need not be carried out at the 
same time or at the same location (though it is, of 
course, convenient to do so), the changing of the source 
address must be done whilst the initial virtual destina- 
tion address is still available. 

The contents of datagram 25AA are passed by IP 
layer 20 of machine T to a high-level application which, 
in the present example, produces a reply that it passes 
to layer 20 for sending back to IP address I^hq), that is, to 
the source address contained in datagram 25AA. Layer 
20 produces a datagram 25B with source address \j 
and destination address I^q). Next, IP-to-SVC task 30 of 
layer 21 looks up the destination address in the cache 
table 27 to find out the SVC to be used for the reply If, 
as will normally be the case, the same SVC is to be 
used for the reply as carried the original datagram 25A 
with destination address [j^, then the SVC setup proc- 
ess will have been arranged to enter the address I^q) in 
cache table 27 against that SVC (in present case, iden- 
tified to machine T by "q"): a lookup on I^q will thus 
return "q" as the required SVC. However, if it is desired 
to use a different SVC for datagrams 25B passing from 
T to M as used for datagrams 25A passing from M to T, 
then the first lookup on I^q) by task 30 will not identify an 



SVC and task 30 must then initiate set up of a new SVC. 
Assuming that the same SVC is to be used for the 
' datagrams 25B with destination address I^q) as for the 
datagrams 25A with destination address lx(i). then alter 

5 task 30 has identified SVC(q) as the appropriate SVC, 
the datagram 258 is passed to the ATM layer 22 for 
sending out over SVC(q). In due course, machine M 
receives this datagram and passes it up to IP layer 20; 
however, before the datagram reaches this layer. It must 

10 undergo address-change processing similar to that car- 
ried out on datagram 25A. More particularly, the virtual 
destination address I^q must be changed to the real IP 
address Im of machine M, and the real source address 
Ij of machine T must be changed to the virtual IP 

15 address lT(i) of machine T associated with the virtual 
destination address Imq^. This address-change process- 
ing is carried out by process 71. 

With regard to the source address change, where 
the con-esponding change was effected for datagram 

20 25A by incrementing by one the virtual destination 
address lT(j) of ttiat datagram, then for datagram 25B, 
the source address is changed to the destination 
address decremented by one. 

In a similar manner to process 70, process 71 nfiust 

25 be can'ied out on datagram 25B after operation of the 
IP-to-SVC task 30 in machine T and prior to the filter 
task 29 in machine M. In addition, whilst tiie two 
address-changing operations of process 71 need not be 
carried out at the same time or at the same location, the 

30 changing of the source address must be done whilst the 
initial virtual destination address is still available. 

Following operation of process 71 , datagram 25BB 
with source address lx(() and destination address 1^ Is 
allowed through by filter task 29 and the contents of the 

35 datagram are passed to the relevant high-level applica- 
tion. 

Having described the general mechanism by which 
virtual IP addresses can be used for exchanging data- 
grams 25A and 256 across a SVC between machines 

40 M and T, the issue will now be addressed as to how the 
cache table 27 in machine T is updated on SVC setip to 
associate the new SVC (that is. SVC(q) at machine T) 
with tiie virtual IP address 1^^) of machine M (this is 
required where the same SVC is to be used for the reply 

45 datagram 25B as for the original datagram 25A). It will 
be appreciated that when the task 40 (see Figure 2) is 
executed, the INARP request sent to machine M will 
only return the real IP address 1^ of machine M, there 
being no other Information available to the update task 

50 40 by which any other result could be obtained from tiie 
INARP task 50; clearly, sometiiing additonal needs to 
be done for update task 40 to be able to associate the 
virtual IP address I^q with ttie newly created SVC{q) in 
table 27. In fact, there are a number of ways In which tiie 

55 update task could be informed that tiie IP address to be 
associated with SVC(q) is 1^(1). For example, the update 
task 40 couM be arranged to send a request back over 
the newly-created SVC(q) asking machine M to identify 
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the destination IP address Ij^ it associates with that 
SVC; from this information, the update task oould deter- 
mine the associated virtual IP address I^q) of machine 
M (assuming there is a predete'mined relation between 
the two as is the case in the described embodiment) 
and then update table 27 accordingly. An alternative 
approach that avoids sending a special request to 
machine M is to wait for nrtachine M to supply the desti- 
nation IP address lT(j) in the first IP datagram 25A sent 
over the new SVC(q). the update task then deriving the 
required address as described above. 

A variant of this latter approach is to leave tiie 
update task 40 unchanged but provide an additional 
process tiiat: 

(a) delays the INARP request until the destination 
address Ijq of the first datagram from machine M 
to machine T can be captured; 

(b) uses the captured address as the source 
address of the INARP request that is now sent on to 
machine M. 

The INARP response from machine M will therefore 
have a destination address and a source address 
(that fomis the substance of tiie INARP response) of ly. 
By ensuring tiiat tiiis response datagram is subject to 
the processing effected by process 70, the source data 
in the INARP response will be changed to I^^q) by tiie 
time the response reaches the update task 40. Thus, 
the required updating of tiie table 27 of machine T can 
be achieved without modification to the existing tasks of 
machines M and T but simply by the addition of a furtiier 
process for effecting steps (a) and (b) described above. 
This approach is the preferred one for updating table 27 
and is the one used in the module described below with 
reference to Figures 6 and 7. 

The above-described system involving the alloca- 
tion of multiple virtual IP addresses to machines M and 
T and the provision of tiie address-changing processes 
70 and 71, permits multiple SVCs to be concun^entiy 
operated between the machines M and T thereby ena- 
bling implementation of the test arrangement depicted 
in Figure 4. Of course, when testing tiie machine M. it is 
desirable that no changes are made to this machine; 
accordingly, it is prefen^ed for such a test arrangement to 
implement the address-changing processes 70 and 71 
in machine T. 

The implementation of the address-changing proc- 
esses 70 and 71 , and of tiie INARP request modification 
process, can conveniently by done by inserting a mod- 
ule (hereinafter called the VNS module) between the 
IP/ATM layer 21 and the ATM layer 22 of machine T; in 
fact, an instance of this module is created for each SVC, 
this being relatively easy to implement when using a 
STREAMS type I/O implementation as provided in most 
UNIX systems (convenientiy one stream is provided for 
each SVC and the VNS module is pushed onto each 
stream when the stream is created). 



The messages passing across the boundary 
between layers 21 and 22 have already been described 
above witti reference to Figure 2 and tiie processing 
effected by tiie VNS module on each of these messages 

5 will next be described. First, the situation of Figure 5 will 
be considered where It is machine M tiiat initiates tiie 
setting up of a new SVC to machine T. The first mes- 
sage received by tiie VNS module will be tiie SVC setup 
indication message XS*^ and tiiis is passed tiirough tiie 

10 VNS HfKXlule witiiout modification (see Figure 6). Next, 
tiie INARP request X6^ is received and is subject to tiie 
modification process 82 described above, namely it is 
delayed until the first IP datagram 25A is received and 
the address extracted and used for the source 

15 address of the INARP request. The INARP response 
X7^ is tiien received and subject to the address-chang- 
ing process 70. IP datagrams X8^ from machine M to 
machine T are also subject to tiie address-changing 
process 70. IP datagrams X8^ from machine T to 

20 machine M are subject to address-changing process 
71. 

Figure 7 depicts the processing effected by tiie 
VNS module in tiie situation where it is the machine T 
ratiier tiian tiie machine M tiiat initiates SVC setup. The 
25 messages passing through tiie VNS module in tills case 
are those shown crossing tiie boundary between layers 
21 and 22 in Figure 2 for machine M. The first four mes- 
sages XI ^, X3^, X2", and X4" are passed through with- 
out modification. The INARP request received from 
30 machine M is subject to tiie modification process 82. 
being delayed until the destination address of the first IP 
datagram from machine T to machine M can be cap- 
tured and used as the source address of tiie INARP 
request. TTie INARP response X7^ is subjected to proc- 
35 ess 71 as are IP datagrams X8^ from machine T to 
machine M. IP datagrams X8^ from machine M to 
machine T are subjected to process 70. 

It will be appreciated that many variants are possi- 
ble to the above-described embodiment of tiie inven- 
40 tion. It will also be appreciated tiiat the invention is not 
limited to switched virtual circuits but can equally be 
applied to permanent virtual circuits. Furthermore, tiie 
setting up of multiple virtual circuits between two 
machines can be used not only for implementing tiie 
45 test arrangement described above with reference to Rg- 
ure 4 but also for otiier purposes. 

Altfiough the present invention has been described 
in tiie context of high-level addresses constituted by IP 
addresses and virtual circuits set up across an ATM net- 
so work, the invention can be applied to other types high- 
level addresses and other types of virtual-circuit net- 
work. For example, the high-level addresses oould be 
MAC addresses in the case of a network in tiie form of 
a emulated LAN (ELAN) over an ATM network. 

55 

Claims 

1. A system in which a plurality of entities are con- 
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nected to a network and can exchange messages 
across virtual circuits set up over the network 
between said entities, each entity having an opera- 
tive high-level address on the networK and each 
said entity comprising: 5 

- high-level messaging means for handling 
message transmission and receipt on the basis 
of said high-level addresses, said high-level 
messaging means comprising means for 10 
including in outgoing ones of said messages 
the operative high-level address of the entity as 

a source identifier and the operative high level 
address of the Intended recipient entity as a 
destination identifier, and means for filtering is 
incoming ones of said messages according to 
the destination identifier contained in the mes- 
sage: 

~ virtual-circuit means for providing virtual cir- 
cuits between the entity and other said entities, 20 
there being a respective virtual circuit for each 
different destination identifier in use, and 

- intermediate means for passing an outgoing 
message from said high-level messaging 
means to that one of the virtual circuits pro- 2S 
vided by the virtual-circuit means which corre- 
sponds' to the destination identifier of the 
message; 

characterised in that each of a first and a second 30 
said entity has a plurality of virtual high-level 
addresses associated with it that are different from 
said operative high-level address of the entity, said 
virtual high-level addresses being usable by the 
messaging means of said first and second entities 35 
as destination identifiers in outgoing messages; 
and in that between said intermediate means of 
said first and second entities, there are provided 
address-changing means responsive to each of at 
least some of said messages sent between these 40 
entities with a said virtual high-level address as its 
destination identifier to change that address to the 
said operative high-level address of tfie corre- 
sponding entity, and to change the operative high- 
level address provided as the source identifier of 45 
the message into one of the said virtual high-level 
addresses associated with the sending entity in 
dependence on tiie virtual high-level address ini- 
tially provided as the destination identifier of the 
same message. so 

2. A system according to claim 1, wherein said 
address-changing means effects a predetermined 
transformation on the virtual high-level address 
forming the initial destination identifier of a said ss 
message to which the address-hanging means is 
responsive in order to form tiie virtual high-level 
address to be used for the source identifier of that 



message. 

3. A system according to claim 2. wherein said 
address-changing means is responsive to mes- 
sages sent in both directions between said first and 
second entities with virtual high-level addresses as 
destination identifiers, tiie said ti-ansformation 
effected in respect of such messages sent in one 
said direction being tfie reverse of ttie transforma- 
tion effected in respect of other such messages 
sent in the opposite said direction. 

4. A system according to claim 1, wherein said 
address-changing means comprises first address- 
changing functionality for effecting said changes for 
messages sent from said first entity to said second 
entity, and second address-changing functionality 
for effecting said changes for messages sent from 
said second entity to said first entity, botii said first 
and second address-changing functionalities being 
provided in said second entity. 

5. A system according to claim 1. wherein said 
address-changing means comprises first address- 
changing functionality for effecting sard changes for 
messages sent from said first entity to said second 
entity, and second address-changing functionality 
for effecting said changes for messages sent from 
said second entity to said first entity, the two said 
address-changing functionalities being provided in 
respective ones of said first and second entities. 

6. A system accorcfing to daim 1 , wherein: 

- each said entity has a low-level address on 
the network; 

- said intermediate means of each entity fur- 
ther conprises: 

- first association means for providing an 
association between the destination identi- 
fier of a outgoing message and tiie low- 
level address of tiie con'esponding said 
entity, 

" second association means for providing 
an association between the destination 
identifier of an outgoing message and a 
said virtual circuit, 

said intermediate means using its second 
association means to identify from tiie destina- 
tion identifier of a said outgoing message which 
virtual circuit is to be passed tiie message 
where such virtual circuit exists, and otherwise 
first passing a request to the said virtual circuit 
means of the same entity to establish a virtual 
circuit to ttie entity having the low-level address 
identified by said first association means as 
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associated with the destination identifier of the 
outgoing message; and 
- the said virtual-circuit means of each entity 
includes setup means responsive to a said 
request from the intermediate means of the 5 
same entity to establish a virtual circuit to the 
said entity having the low-level address pro- 
vided in said request, said setup means caus- 
ing the intermediate means to update its 
second association means to associate the 10 
newly-established virtual circuit with the said 
destination identifier relevant to said request: 

the first association means of each of said first and 
second entities serving to provide an association is 
between the virtual high-level addresses of the 
other of said first and second entities and the low- 
level address of that other entity 

8. A system according to daim 7, further compris- 20 
ing a network server containing associations 
between high-level addresses and low-level 
addresses, said first association means of each 
said entity corrprising means for interrogating said 
network server for a required association. 25 

9. A system according to claim 7, wherein said sec- 
ond association means comprises cache means for 
temporarily holding said associations between said 
destination identifiers and currently corresponding 30 
virtual circuits. 

10. A system according to any one of claims 1 to 9, 
wherein said high-level addresses are IP addresses 
and said network is a AT1VI network. 3S 

11 . A system according to any one of claims 1 to 9, 
wherein said high-level addresses are MAC 
addresses and said network is a emulated LAN 
over an ATM network. 40 

12. A method of testing the ability of network node 
apparatus to operate a plurality of virtual circuits at 
the same time, said network node apparatus being 
an^anged to establish a virtual circuit for each differ- 45 
ent high-level destination address being handled, 
said method involving setting up a system accord- 
ing to claim 4 with said network node apparatus as 
said first entity, and causing the network node 
apparatus to send messages to at least some of so 
said virtual high-level addresses associated with 
said second entity. 
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